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INTRODUCTION 


Three  Corner  Satellite  Description 

The  Three  Comer  Satellite  (3CS)  constellation  is  a  cluster  of  three  nanosatellites  that  are  part  of 
the  US  Air  Force  University  Nanosat  program.  The  3CS  project  was  begun  in  January  1999  and 
the  cluster  of  satellites  is  presently  awaiting  launch  in  2003  from  the  Space  Shuttle.  The  satellites 
are  shown  in  their  launch  configuration  in  Figure.  1.  The  3CS  project  is  a  joint  effort  of  the 
faculty,  staff,  and  students  at  the  participating  universities:  Arizona  State  University  (ASU),  the 
University  of  Colorado  at  Boulder  (CU),  and  New  Mexico  State  University  (NMSU).  Consult 
the  [Unde  99],  [Hans  99]  and  [Hora  99]  for  further  details  on  the  baseline  design  and  mission 
concepts. 

The  3CS  mission  has  four  primary  and  three  secondary  objectives.  The  primary  mission 
objectives  include:  stereo  imaging,  virtual  formation  flying,  inter-satellite  communications,  and 
end  to  end  command  and  data  handling.  The  science  will  include  imaging  of  clouds  and  other 
atmospheric  structures  using  a  satellite  formation.  After  deployment,  the  three  satellites  will 
operate  together  using  formation  flying  techniques.  This  will  be  accomplished  while  using 
virtual  formation  communications,  a  technology  that  allows  the  satellites  to  operate  as  a  network 
utilizing  communication  and  data  links.  Finally,  the  formation  will  use  distributed  and  automated 
operations.  This  allows  both  individual  nanosats  and  the  entire  formation  to  be  reconfigured  for 
optimum  data  gathering,  command  and  control,  and  communication. 

The  secondary  mission  objectives  include:  validation  of  a  MEMS  heater  chip  for  a  Free 
Molecule  Micro  Resistojet  (FMMR)  propulsion  system,  demonstration  of  generic  nanosatellite 
bus  design,  and  student  education. 

One  of  the  principal  features  of  the  3CS  mission  is  that  all  three  nanosats  are  based  on  a  similar 
design.  Each  university  has  responsibility  for  different  subsystems,  and  all  components  are 
designed  to  be  common  to  each  of  the  satellites.  Each  school's  team  is  comprised  of  a  faculty 
member  and  graduate  and  undergraduate  students.  Each  school  leads  in  its  respective  areas  of 
expertise  and  on  strengths  proven  on  past  projects  as  follows: 

a.  ASU  -  program  management,  systems,  structures,  electrical  power,  micropropulsion, 
integration  and  testing,  safety,  configuration  management  and  quality  assurance, 

b.  CU  -  science  (imaging),  command  and  data  handling,  mission  operations,  and 

c.  NMSU  -  communications. 

Using  this  team  concept,  the  design  was  developed  at  the  lead  school  with  review  and  comment 
by  the  partner  schools.  In  addition  to  the  design  work,  the  team  members  needed  to  verify  that 
all  components,  materials,  and  design  features  would  pass  the  NASA  flight  safety  reviews  for 
launch  from  the  Space  Shuttle.  This  paper  concentrates  on  the  design  of  the  satellites.  Since  the 
individual  subsystems  were  produced  by  different  partner  members  at  each  school,  the  overall  set 
of  components  needed  to  be  matched  and  integrated  at  final  assembly. 

The  3CS  satellites  were  designed  and  fabricated  as  three  common  satellites.  The  main 
differences  are  antenna  placement,  the  inclusion  of  the  FMMR  test  electronics  on  two  cluster 
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Figure  1  —  3  Comer  Satellite  launch  configuration. 
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members,  and  some  additional  solar  cells  on  one  satellite.  In  this  section,  we  will  describe  the 
common  components  for  each  satellite  necessary  for  the  formation  flying  mission  goals.  This 
includes  the  structure,  the  power  system,  the  end-to-end  data  system,  the  imaging  system,  and  the 
communications  system. 

The  structure  for  each  satellite  is  based  on  a  machined  6061 -T6  aluminum  isogrid  structure  as 
illustrated  in  Figure  2.  The  structure  is  hexagonal  in  cross  section  with  the  major  axis  for  the 
satellite  being  44.7  cm  and  the  minor  axis  for  the  satellite  is  39.4  cm.  The  height  of  each  satellite 
is  29.2  cm.  As  can  be  seen  in  Figure  2,  the  side  panels  and  the  top  and  bottom  plates  form  an 
interlocking  structure.  Brackets  are  added  where  the  side  panels  abut  for  increased  rigidity.  The 
aluminum  is  anodized  except  for  electrical  contact  points.  The  side  and  top  panels  are  the  load- 
bearing  structure  for  the  satellite.  The  structure  was  tested  to  verify  that  it  would  meet  required 
strength  and  vibration  mode  requirements  for  a  space  shuttle  payload. 

The  Electrical  Power  System  (EPS)  is  composed  of  the  following  elements 

a.  solar  cells, 

b.  battery  pack, 

c.  inhibit  relays, 

d.  DC/DC  converter,  and 

e.  microprocessor  controller. 

The  system  elements  are  organized  as  illustrated  in  Figure  3.  The  power  from  the  battery  and  the 
solar  cells  is  distributed  as  +5  V  regulated  and  +12  V  unregulated  power.  The  12-V  power  is 
used  by  the  cameras  and  imaging  electronics.  The  5-V  power  is  for  other  components.  All 
systems  but  EPS  have  in-line  switches  controlled  by  EPS  to  prevent  power-on  prior  to  safe 
operating  conditions  being  established  after  launch  and  to  control  the  satellite  power  budget. 
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b.  listening  for  end-to-end  data  system  commands  to  enable/disable  individual  components, 
and 

c.  acting  as  a  watchdog  timer  for  the  end-to-end  data  system. 

The  inhibit  relays  are  required  to  prevent  premature  energizing  of  the  electronics  during  launch. 
There  are  three  latching  relays  between  each  power  source  and  the  load.  There  is  also  one 
latching  relay  in  the  ground  leg  for  each  power  source.  These  relays  are  set  by  the  inhibit  timer 
electronics  in  the  MSDS  portion  of  the  launch  configuration. 

The  solar  panels  use  dual-junction  gallium  arsenide  solar  cells  that  are  commercially 
manufactured.  The  side  panels  and  top  panel  of  each  satellite  holds  the  solar  panel  structure  in 
place.  Each  panel  consists  of  two  strings  of  nine  cells  with  each  cell  generating  approximately 
2.4  V.  The  solar  panel  contains  a  current  meter  and  diode  protection.  The  solar  panel 
configuration  is  shown  in  the  left  half  of  Figure  4 

The  battery  portion  of  the  EPS  is  composed  of  a  pack  of  ten  NiCd  cells  with  2300  mAh  of 
capacity.  The  battery  is  illustrated  in  the  right  half  of  Figure  4  which  shows  the  packaging  into  a 
vented  box  with  absorbent  material  to  mitigate  any  leakage  effects. 
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Figure  4  —  3CS  solar  cell  and  battery  configuration. 


he  End-to-End  Data  System  (EEDS)  is  an  integration  of  computer  hardware,  software, 
procedures,  and  personnel  for  cluster  command  and  control  and  data  handling.  The  hardware 
component  in  each  satellite  includes  an  823  Power  PC  flight  computer  having  16  MB  of  RAM,  8 
MB  of  RAM  organized  as  a  solid  state  recorder,  and  a  critical  decoder  for  processing 
initialization  commands. 

The  software  is  stored  on  disk  and  in  ROM.  The  flight  software  is  disabled  until  after 
deployment  from  the  MSDS.  The  software  uses  a  commercial  operating  system  (VxWorks)  and 
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extensive  use  of  commercial  software  tools  for  controlling  the  satellites.  The  primary  tool  is  the 
System  Control  Language  (SCL)  to  program  rules  to  monitor  the  health  and  welfare  of  the 
satellite.  The  current  state  of  the  satellite  can  initiate  scripts  to  take  counter  measures  for 
detected  faults.  The  rules  can  also  be  used  to  generate  scripts  to  perform  specific  functions,  e.g. 
initialize  the  radio  system  or  the  imaging  system.  Operational  science  events  such  as  taking  a 
sequence  of  pictures  are  also  SCL-based  activities. 

The  command  structure  for  the  satellites  is  based  on  specific  files  sent  from  the  ground  stations, 
inter-satellite  messages,  and  pre-stored,  timed  commands.  The  scheduling  software  can  build  a 
sequence  of  operational  commands  to  be  executed  between  ground  station  contact  times. 

The  imaging  system  for  the  satellites  is  based  on  four  cameras  per  satellite  with  the  goal  of 
producing  images  of  clouds  from  orbit.  There  are  two  cameras  on  the  top  bulkhead  and  two 
cameras  on  the  bottom  bulkhead.  The  cameras  interface  with  EEDS  for  data  and  EPS  for  power. 
The  cameras  are  commercial  cameras  using  a  640  x  480  pixel  CMOS  sensor.  The  cameras  have 
full  automatic  exposure  control.  The  on-board  algorithms  will  be  used  to  evaluate  image  quality 
and  prioritize  the  images  for  downloading.  The  imaging  cameras  are  illustrated  in  the  right 
portion  of  Figure  5  and  the  mounting  in  the  bulkhead  in  shown  in  the  left  portion  of  Figure  5. 


Figure  5  --  3CS  imaging  system. 

The  communications  system  is  based  on  commercial  amateur  radio  hardware  that  has  been 
modified  for  an  extended  frequency  range  outside  the  amateur  bands.  The  radios  are  arranged  as 
a  dual  redundant  flight  radio  in  each  satellite.  Each  radio  is  software  programmable  via  the 
EEDS  to  set  frequency,  power,  and  operating  characteristics.  The  radios  are  only  powered  on 
when  supplied  power  by  the  EPS  to  help  control  the  overall  satellite  power  budget  with  each 
radio  being  individually  powered.  The  nominal  operating  mode  will  be  to  have  one  radio  on  at 
all  times  in  receive  mode  to  listen  for  commands.  The  radios  use  a  VHF  frequency  for  the  data 
downlink,  UHF  frequency  for  the  command  uplink,  and  a  different  UHF  frequency  for  the  inter¬ 
satellite  crosslink  communications.  All  communications  use  a  frequency  shift  keying  technique 
and  the  AX.25  packet  communications  protocol  at  the  physical  channel  level.  The  data  rates 
available  on  the  radios  are  1200  bps  and  9600  bps.  The  maximum  transmission  power  is  1  W. 
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The  antenna  system  uses  a  commercial  dual-band  antenna  for  each  radio.  The  antennas  on  the 
two  satellites  that  are  joined  in  the  2  x  1  launch  configuration  have  their  antennas  inserted  into  a 
sheath  inside  the  other  satellite  for  launch.  Upon  satellite  separation,  the  antennas  are  withdrawn 
from  the  sheaths  without  use  of  a  deployment  mechanism. 

The  primary  ground  control  station  will  be  at  CU.  The  other  schools  (ASU  and  NMSU)  will 
have  compatible  ground  stations  to  be  used  as  backup  relay  points  for  both  commands  and 
telemetry  by  using  store  and  forward  data  files  in  either  direction.  The  uplink  data  files  can  be 
commands,  schedules,  or  revised  software.  The  relationship  between  the  satellites  and  the 
ground  stations  is  illustrated  in  Figure  6. 


Space  Telecommand,  Meteorological  Satellite 
Service,  and  Inter-Satellite  Service 
3  Corner  Sdtel  I  ite  Constel  I  ati  on 
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Figure  6  --  3CS  communications  links. 


The  satellite  cluster  launch  configuration  was  shown  in  Figure  1.  The  2x1  satellite  configuration 
was  determined  by  vibration  limits  on  the  satellite  separation  systems.  This  configuration 
consists  of 

a.  the  individual  satellites 

b.  the  Lightband  inter-satellite  separation  mechanism  between  the  two  joined  satellites 

c.  the  Starsys  separation  mechanism  between  the  launch  plate  and  the  satellite  on  it 

d.  the  Multiple  Satellite  Deployment  System  (MSDS)  that  holds  the  cluster  configuration. 
For  the  purposes  of  this  project,  the  Lightband,  Starsys,  and  MSDS  components  are  “government 
furnished  equipment”  and  outside  the  control  of  the  3CS  project  team.  However,  the  satellites 
need  to  be  compatible  with  the  components.  Additionally,  the  timer  control  and  power  for 
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removing  the  inhibits  are  controlled  through  the  MSDS  electronics.  The  electronic  signals  for 
activating  the  satellites  are  passed  through  the  Starsys  and  Lightband  components  to  the  cluster 
members.  This  integrated  system  is  delivered  to  NASA  to  be  mated  with  the  NASA  systems  for 
launch. 

Scope 

The  remainder  of  this  report  deals  with  the  development  of  the  3CS  communications  system  for 
the  actual  flight  system.  The  initial  report  for  this  project  included  a  copy  of  the  MSEE  Thesis 
from  Mr.  Bobby  Anderson  that  provided  an  initial  design  for  the  communications  system.  This 
final  report  describes  the  “as-built”  communications  subsystem  for  the  satellites. 

Topic  Development 

The  next  section  is  the  detailed  description  of  the  flight  radio  development.  In  it,  we  discuss  the 
design  constrains  and  limits  on  developing  the  hardware,  the  testing  to  validate  the  components, 
and  the  production  of  the  actual  flight  units.  For  the  full  details  of  the  design,  consult  the 
documentation  supplied  with  the  flight  units. 

The  Appendices  hold  the  three  papers  on  the  development  of  the  system  that  were  presented  at 
conferences  this  year. 
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FLIGHT  COMMUNICATIONS  SYSTEM  DESIGN 


To  produce  a  flight  radio  system  that  would  be  usable  across  all  three  satellites,  we  needed  to 
base  the  design  on  a  tight  set  of  constraints  and  design  goals.  The  following  paragraphs  indicate 
the  system  constraints  and  the  design  goals  for  the  flight  radio. 

Constraints 

The  largest  constraint  on  the  radio  design  was  imposed  by  the  power  system.  The  total  power 
budget  for  each  satellite  was  expected  to  be  approximately  10  W.  From  this,  communications 
would  be  allocated  5  W  from  a  regulated,  5-V  power  bus  on  a  shared  basis  with  other  subsystems 
since  communications  would  not  be  active  at  all  times.  The  requirement  for  the  radio  system 
was  that  it  operate  with  an  input  voltage  of  5  V  and  draw  no  more  than  1  A  when  operating.  Due 
to  inefficiencies  and  the  slim  power  margins  to  begin  with,  it  was  not  considered  effective  to  use 
a  DC-DC  converter  to  raise  the  input  voltage  to  a  higher  level. 

The  next  constraint  was  that  the  radio  system  would  need  to  support  command  services, 
downlink  services,  and  inter-satellite  services.  The  intention  was  to  use  the  available  allocations 
in  the  UHF  and  VFH  bands,  respectively,  for  the  first  two  services.  The  inter-satellite  service 
would  be  run  as  an  amateur  radio  experiment  utilizing  packet  radio  and  APRS  techniques.  The 
minimum  data  rate  for  the  command  and  inter-satellite  services  would  be  1200  bits  per  second 
while  the  minimum  data  rate  for  the  telemetry  data  would  be  9600  bits  per  second. 

The  solution  for  the  flight  radio  system  would  need  to  meet  the  3CS  size  and  weight  constraints. 
While  this  never  became  a  major  issue,  the  overall  design  team  tried  to  minimize  weight 
whenever  possible  because  the  satellite  stack  was  always  close  to  its  maximum  allowed  weight 
based  on  launch  constraints. 

Any  system  that  was  chosen  would  need  to  pass  qualification  testing.  The  radio  system  would 
be  designed  to  survive  the  Hitchhiker  vibration  qualification  testing.  [NAS  99]  The  radio  would 
also  need  to  survive  thermal  cycles  from  -20°  C  to  +  60°  C. 

One  design  constraint  that  was  explicitly  not  imposed  was  for  the  components  to  be  radiation 
hardened.  This  decision  was  made,  primarily,  because  the  expected  lifetime  of  the  satellites  on 
orbit  would  be  only  a  few  months.  Given  this  short  expected  mission  lifetime,  it  was  decided  not 
to  expend  the  extra  cost  for  explicit  radiation  hardening.  The  project  team  decided  that  between 
having  the  radios  mounted  in  aluminum  boxes,  the  use  of  a  redundant  configuration,  and  the 
ability  to  reset  the  radios  via  the  flight  computer,  the  risk  of  total  failure  due  to  radiation  effects 
would  be  small  enough  to  warrant  using  commercial-grade  parts. 

Goals 

The  first  design  goal  was  to  provide  for  all  of  the  radio  services  in  a  single  unit  rather  than 
having  frequency-specific  radios.  This  would  help  minimize  weight  and  total  power 
consumption.  If  a  single  radio  could  be  used,  a  secondary  design  goal  would  be  for  the  flight 
radio  subsystem  to  provide  a  software  control  of  frequency  settings  and  radio  parameters  that 
would  be  under  the  control  of  the  flight  computer  that  would  be  scheduling  operations.  The  final 


8 


design  goal  was  to  provide  for  a  redundant  design  to  allow  for  a  graceful  failure  of  the  flight 
radio  subsystem.  The  frequencies  chosen  for  the  actual  transmissions  as  requested  on  the 
DD1494  form  submitted  to  the  Air  Force  spectrum  management  office  and  the  Federal 
Communications  Commission  are  listed  in  Table  1. 


Table  1  -  Requested  Frequencies  for  the  3  Corner  Satellite  Project. 

Frequency 

Usage 

137.725  MHz 

Data  downlink  (telemetry  and  images) 

449.90  MHz 

Command  uplink 

437.5  MHz 

Inter-satellite  service 

Design  Solution 

The  design  of  the  flight  radio  was  based  on  an  existing  commercially-available  product.  The 
following  paragraphs  describe  why  the  components  were  chosen  and  how  the  components  were 
modified  for  flight. 

Radio  Choice 

Based  on  the  design  constraints,  the  Kenwood  TH-D7  transceiver  was  chosen  as  the  basis  for  the 
3CS  flight  radio.  The  following  features  were  key  to  selecting  this  particular  model: 

a.  The  radio  would  operate  with  a  5  V  supply  voltage  and  consume  approximately  1  A  of 
current  at  the  highest  power  mode 

b.  The  radio  has  two  lower  power  settings  thereby  allowing  for  power  control  options 

c.  The  radio  has  a  standard  RS-232  interface  for  data  and  control 

d.  The  radio  has  an  integrated  modem  thereby  eliminating  the  need  for  an  external  modem. 
The  radio  also  provided  internal  support  for  packet  communications  modes  that  can  be 
customized  by  commands  from  the  flight  computer. 

e.  The  radio  could  be  easily  modified  for  the  UHF  and  VHF  services  required.  The  radio 
had  built-in  support  for  the  inter-satellite  link. 

An  additional  feature  that  was  found  to  be  useful  was  that  the  TH-D7  stores  its  settings  to 
memory  so  that  they  are  not  lost  when  the  radio  is  powered  off.  This  implies  that  the  flight 
software  does  not  need  to  re-load  settings  each  time.  However,  this  would  remain  an  option  to 
help  recover  from  single-event  upsets. 

Because  the  basic  radio  components  were  relatively  light  when  removed  from  the  commercial 
housing,  we  proceeded  to  design  a  system  with  two  TH-D7  units  to  form  a  redundant  flight  radio 
subsystem.  The  necessary  modifications  are  next  described. 

Necessary  Modifications 

Because  the  TH-D7  was  intended  for  a  commercial  market,  it  has  a  number  of  components  that 
would  either  be  unnecessary  in  a  flight  radio  (speaker  and  microphone)  or  not  allowed  (zinc 
alloy  plate  and  various  plastics).  By  using  an  iterative  process,  a  procedure  was  developed  to 
exactly  modify  the  radio  to  first  maintain  functionality  and  second  to  eliminate  all  components 
that  were  not  necessary  for  flight  or  had  to  be  modified  to  pass  materials  compatibility.  The 
main  materials  problem  was  with  the  zinc  alloy  chassis  plate  used  in  the  radio.  This  was 
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replaced  by  an  equivalent  aluminum  plate  of  the  same  form  factor.  The  procedure  was  codified 
into  a  step-by-step  procedure  to  be  used  in  preparing  the  actual  flight  radios  [Hor  Ola].  Figure  7 
illustrates  an  exploded  view  of  the  initial  radio  components  and  the  ones  finally  kept  in  the  flight 
units.  The  circuit  boards  were  conformal  coated  and  held  together  with  staking  compound  and 
lacing  cord  as  shown  in  Figure  8.  The  main  functional  modification  to  the  radio  was  to  wire  it  to 
always  to  be  “on”  so  that  it  would  be  operational  whenever  power  was  applied. 

During  testing  of  the  radio’s  performance,  we  discovered  that  the  manufacturer-supplied  dual¬ 
band  antenna  did  not  perform  well  at  VHF  frequencies.  The  performance  was  10  dB  below  that 
of  a  tuned  blade  antenna  for  the  VHF  frequency.  We  replaced  the  stock  dual-band  antenna  with 
a  different  commercial  dual-band  antenna  that  was  only  5  dB  below  the  tuned  blade  performance 
at  VHF  and  within  1  dB  of  tuned  blade  performance  at  UHF. 

Redundant  Design 

One  of  the  design  goals  was  to  produce  a  redundant  flight  radio  sub-system  for  the  3CS  satellites. 
The  design  was  realized  by  using  two  TH-D7’s  in  a  primary  and  backup  configuration.  Each 
radio  would  individually  receive  power  only  when  the  power  sub-system  was  commanded  to  do 
so  by  the  flight  computer.  Each  radio  was  individually  addressable  by  the  flight  computer 
through  its  RS-232  data  port.  Each  radio  uses  its  own  dual-band  antenna  (no  antenna  cross 
switching).  A  Basic  Stamp  microcontroller  was  added  to  the  design  to  ensure  proper  radio 
power  up.  Through  testing,  we  found  that  on  occasion,  the  TH-D7  would  not  properly  initialize 
when  power  was  first  applied.  The  microcontroller  monitors  the  input  line  to  determine  when 
the  radios  are  powered.  If  the  microcontroller  detects  that  power  has  been  applied  to  the  radio 
but  the  radio  does  not  activate,  then  the  microcontroller  strobes  the  corresponding  TH-D7  to 
emulate  a  user  cycling  the  on/off  switch.  We  have  found  that  the  radio  will  properly  activate 
after  this  procedure.  A  separate  circuit  board  was  designed  and  fabricated  for  the 
microcontroller  and  added  to  the  overall  flight  radio  design. 

Each  subsystem  in  the  3CS  design  is  housed  in  its  own  aluminum  box  to  provide  low-level 
radiation  shielding  and  to  provide  some  radio  frequency  isolation  and  minimize  interference 
between  subsystems.  The  flight  radio  is  no  exception.  The  housing  for  the  flight  radio  was 
designed  to  hold  both  TH-D7  radio  circuit  boards  and  the  microcontroller  circuit  board.  After 
assembly,  the  radio  units  were  delivered  to  ASU  for  integration  with  the  other  satellite 
components. 

The  wiring  diagram  for  the  redundant  configuration  is  illustrated  in  Figure  9  and  one  of  the  flight 
units  being  assembled  with  its  aluminum  housing  is  illustrated  in  Figure  10.  A  manual  for  the 
integrated  design  was  produced  to  guide  software  developers  and  for  operations  training.  [Hor 
02] 

Design  Validation  and  Testing 

To  validate  the  design,  an  extensive  test  program  was  developed  to  ensure  that  no  functionality 
was  lost  as  the  radios  were  modified,  assembled  into  the  flight  units,  and  then  delivered  for  ^ 
integration  into  the  satellite.  The  first  step  in  the  process  was  to  start  with  the  Manufacturer  s 
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EXPLODED  VIEW 


Fllght-modHied 

radio 

components 


Zinc  chassis  replaced  with 
Aluminum  equivalent 


Figure  7  -  Original  TH-D7  components  and  the  parts  kept  for  the  flight  radio  subsystem. 


Figure  8  -  Modified  TH-D7  boards  that  are  conformal  coated  and  use  staking  compound  to 
separate  the  boards. 
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Teflon  Coated  Wire 
RG-316/U  Cable 


Figure  9  --  Wiring  diagram  for  the  flight  radio  components. 
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Figure  10  --  3CS  flight  radio  components. 


Acceptance  Test  Plan  where  the  required  functions  were  tested,  operational  voltage  and  power 
confirmed,  and  radio  transmission  format  and  power  were  validated  [Hor  01b].  This  test  was 
derived  from  extensive  experimenting  with  the  radio’s  performance  and  developing  automated 
scripts  that  would  exercise  the  radio’s  set  up  and  configuration.  This  test  became  the  baseline  for 
subsequent  functional  and  characterization  testing.  The  test  sequence  was  also  used  to  illustrate 
how  the  radios  could  be  programmed  for  the  software  development  team.  After  the  electronics 
on  each  TH-D7  were  modified,  and  before  assembling  into  the  flight  unit,  the  individual  unit  was 
tested  for  proper  functionality.  This  test  was  then  performed  again  after  flight  unit  assembly. 
This  test  procedure  could  then  be  re-run  after  other  testing  to  validate  proper  functionality. 

To  validate  that  the  flight  radio  would  pass  acceptance  testing,  an  engineering  unit  was  produced 
and  subjected  to  thermal  cycle  testing  and  vibration  testing.  The  vibration  testing  was  at  full 


shuttle  qualification  levels.  A  visual  inspection  and  a  test  for  proper  functionality  were 
performed  after  the  vibration  testing  to  ensure  that  the  units  survived. 

Finally,  a  link  analysis  was  performed  to  ensure  that  link  closure  would  be  possible  with  the 
radio  system  [Hor  00].  While  link  closure  is  possible,  it  may  not  be  possible  to  downlink  an 
entire  uncompressed  image  during  a  single  pass  to  a  single  ground  station.  It  may  be  required  to 
have  several  ground  stations  receive  the  image  segments  and  then  re-integrate  the  image  in 
software. 
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GROUND  COMMUNICATIONS  NETWORK 

A  design  is  currently  underway  to  link  the  universities  in  the  3CS  team  to  allow  the  transmission 
of  data  between  the  ground  stations.  This  software  is  being  developed  in  the  Lab  VIEW 
environment  and  currently  undergoing  testing.  The  baseline  description  is  given  in  [Mau  02] 
which  is  included  in  the  Appendix  to  this  report. 

The  requirements  for  the  ground  networking  software  are  given  in  Table  2.  These  are  realized  as 
a  set  of  Virtual  Instruments  (VI)  in  the  Lab  VIEW  code.  Much  of  this  code  is  based  upon  the  Vis 
developed  for  unit  testing  the  flight  radios  at  NMSU. 

To  date,  the  basic  testing  of  this  software  has  shown  that  the  students  at  the  University  of 
Colorado  can  control  the  computers  at  New  Mexico  State  University.  Further  testing  will 
continue. 
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Table  2  -  Ground  Networking  Software  Requirements 

No. 

Requirement 

GND.l 

The  Ground  Communications  network  shall  support  a  minimum  of  three  remote 
ground  stations  from  a  control  station 

GND.1.1 

The  Ground  Communications  network  will  provide  a  means  to  remotely  initialize 
each  remote  ground  station 

GND.l. 1.1 

The  initialization  process  will  include  a  means  to  remotely  configure  the  TNC  at 
each  remote  ground  station  .  _ 

GND.l.  1.2 

The  initialization  will  include  a  means  to  remotely  iniate  the  tracking  functions  at 
each  remote  ground  station 

GND.l. 2 

The  Ground  Communications  network  will  provide  a  means  to  monitor  the  status 
of  the  remote  ground  stations 

GND.l. 2.1 

The  status  monitoring  function  will  include  a  means  to  monitor  the  status  of  the 
link  between  the  control  station  and  the  remote  station 

GND.l. 2.2 

The  status  monitoring  function  will  include  a  means  to  monitor  the  number  ot 
bytes  of  data  received  at  the  remote  terminal  on  the  radio  return  link 

GND.l. 3 

The  Ground  Communications  network  will  provide  data  transfer  between  each 
remote  terminal  and  the  central  control  station 

GND.l. 3.1 

The  data  transfer  function  will  include  the  ability  to  transfer  data  in  real  time 

GND.l. 3. 1.1 

The  real  time  data  transmission  will  have  the  means  to  send  data  in  real  time  from 
the  control  station  to  each  remote  terminal 

GND.l. 3. 1.2 

The  real  time  data  transmission  will  have  the  means  to  send  data  in  real  time  from 
each  remote  ground  station  to  the  control  station 

GND.l. 3.2 

The  data  transfer  function  will  include  the  ability  for  store-and-forward  data 
transfer  . . 

GND.l. 3. 2.1 

The  store-and-forward  data  transmission  will  have  the  means  to  send  data  from 
the  control  station  to  each  remote  terminal  for  later  transmission  to  the  satellites 

GND.l. 3.2.2 

The  store-and-forward  data  transmission  will  have  the  means  to  record  satellite 
data  at  each  remote  terminal  for  later  transmission  to  the  control  station  in  the 
event  that  the  internet  link  goes 

GND.2 

The  control  station  and  the  remote  terminals  shall  have  synchronized  clocks 

GND.3 

The  Ground  Communications  network  shall  have  security  measures  that  protect 
unauthorized  use  of  system 

GND.3.1 

The  security  measures  will  prevent  an  unwanted  party  from  having  access  to  the 
control  terminal 

GND.3. 2 

The  security  measures  will  prevent  an  unwanted  party  from  having  access  to  the 
remote  ground  stations 

GND.4 

The  Ground  Communications  network  software  will  be  capable  of  execution  on 
current  Windows  (98/NT/2000/XP),  Unix,  Macintosh,  and  Linux  operating 
systems. 
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CONCLUSIONS 


A  commercial-grade  device  can  be  readied  for  space  flight  and  tested  to  pass  basic  safety  and 
materials  concerns.  The  usual  engineering  lessons  of  adequate  documentation,  well-specified 
procedures,  and  traceable  performance  become  especially  important  when  teaching  students  and 
when  performing  a  distributed  design.  As  might  be  expected,  more  time  is  actually  spent  on  this 
type  of  paperwork  activity  than  on  actual  design  work.  However,  good  documentation  and  good 
practices  make  the  ability  to  work  together  across  school  boundaries  an  achievable  goal. 

The  utilities  and  capabilities  of  the  Lab  VIEW  programming  environment  can  be  used  to  form  the 
basis  for  networking  the  three  universities  in  the  3CS  team. 
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3CS 

LIST  OF  SYMBOLS,  ABBREVIATIONS,  AND  ACRONYMS 

Three  Comer  Satellite 

ASU 

Arizona  State  University 

CU 

Colorado  University 

EEDS 

End-to-End  Data  System 

EPS 

Electrical  Power  System 

FMMR 

Free  Molecule  Micro  Resistojet 

MSDS 

Multiple  Satellite  Deployment  System 

NASA 

National  Aeronautics  and  Space  Administration 

NMSU 

New  Mexico  State  University 

UHF 

Ultra  High  Frequency 

VI 

Virtual  Instrument 

VHF 

Very  High  Frequency 
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Abstract  As  part  of  the  3  Comer  Satellite  program,  a  commercial- grade  amateur  radio 
transceiver  was  adopted  to  be  the  main  flight  radio  due  to  power,  weight,  and  time  constraints. 
While  this  particular  item  was  not  designed  for  space  use,  it  did  have  features  that  would  make  it 
useful  in  the  3CS  mission.  In  this  paper,  we  will  review  the  decision  process  that  led  us  to 
choosing  the  radio  and  describe  the  process  of  modifying  the  radio  for  flight.  This  includes 
issues  related  to  materials,  modifications  necessary  to  the  radio  to  make  it  acceptable,  the 
qualification  testing  required,  and  the  validation  that  performance  quality  was  not  significantly 
lost  in  the  process.  During  this  process,  we  discovered  that  the  radio  can  be  made  acceptable  to 
the  flight  safety  process  provided  that  a  thorough  understanding  of  the  components  is  achieved 
and  a  great  deal  of  experimentation  is  done  before  hand  to  characterize  the  radio. 


Introduction 

The  Three  Comer  Satellite  ( 3CS)  constellation 
is  a  cluster  of  three  nanosatellites  that  are  part 
of  the  US  Air  Force  University  Nanosat 
program.  The  3CS  project  was  begun  in 
January  1999  and  the  cluster  of  satellites  is 
presently  awaiting  launch  in  2003  from  the 
Space  Shuttle.  The  satellites  are  shown  in  their 
launch  configuration  in  Figure  1.  The  3CS 
project  is  a  joint  effort  of  the  faculty,  staff,  and 
students  at  the  participating  universities: 
Arizona  State  University  (ASU),  the 
University  of  Colorado  at  Boulder  (CU),  and 
New  Mexico  State  University  (NMSU). 
Consult  the  references  for  further  details  on 
the  baseline  design  and  mission  concepts.  ’  ’ 

The  3CS  mission  has  four  primary  and  three 
secondary  objectives.  The  primary  mission 
objectives  include:  stereo  imaging,  virtual 
formation  flying,  inter-satellite 

communications,  and  end-to-end  command 


and  data  handling.  The  science  will  include 
imaging  of  clouds  and  other  atmospheric 
structures  using  a  satellite  formation.  After 
deployment,  the  three  satellites  will  operate 
together  using  formation  flying  techniques. 
This  will  be  accomplished  while  using  virtual 
formation  communications,  a  technology  that 
allows  the  satellites  to  operate  as  a  network 
utilizing  communication  and  data  links. 
Finally,  the  formation  will  use  distributed  and 
automated  operations.  This  allows  both 
individual  nanosats  and  the  entire  formation  to 
be  reconfigured  for  optimum  data  gathering, 
command  and  control,  and  communication. 

The  secondary  mission  objectives  include: 
validation  of  a  MEMS  heater  chip  for  a  free 
molecule  micro-resistojet  propulsion  system, 
demonstration  of  generic  nanosatellite  bus 
design,  and  student  education. 

One  of  the  principal  features  of  the  3CS 
mission  is  that  all  three  nanosats  are  based  on 
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Figure  1  -  Completed  3CS  nanosats  in  launch  configuration. 


a  similar  design.  Each  university  has 
responsibility  for  different  subsystems,  and  all 
components  are  designed  to  be  common  to 
each  of  the  satellites.  Each  school's  team  is 
comprised  of  a  faculty  member  and  graduate 
and  undergraduate  students.  Each  school  leads 
in  its  respective  areas  of  expertise  and  on 
strengths  proven  on  past  projects  as  follows: 

•  ASU  -  program  management,  systems, 
structures,  electrical  power, 
micropropulsion,  integration  and 
testing,  safety,  configuration 
management  and  quality  assurance 

•  CU  -  science  (imaging),  command  and 
data  handling,  mission  operations 

•  NMSU  -  communications 

Using  this  team  concept,  the  design  was 
developed  at  the  lead  school  with  review  and 
comment  by  the  partner  schools.  In  addition 
to  the  design  work,  the  team  members  needed 
to  verify  that  all  components,  materials,  and 
design  features  would  pass  the  NASA  flight 
safety  reviews  for  launch  from  the  Space 
Shuttle.  This  paper  concentrates  on  the  design 


of  the  communications  system  that  must 
operate  with  the  overall  cluster  design  and  be 
produced  to  integrate  with  components 
developed  at  the  other  schools. 

Design  Considerations 

To  produce  a  flight  radio  system  that  would  be 
usable  across  all  three  satellites,  we  needed  to 
base  the  design  on  a  tight  set  of  constraints 
and  design  goals.  The  following  paragraphs 
indicate  the  system  constraints  and  the  design 
goals  for  the  flight  radio. 

Constraints 

The  largest  constraint  on  the  radio  design  was 
imposed  by  the  power  system.  The  total 
power  budget  for  each  satellite  was  expected 
to  be  approximately  10  W.  From  this, 
communications  would  be  allocated  5  W  from 
a  regulated,  5-V  power  bus  on  a  shared  basis 
with  other  subsystems  since  communications 
would  not  be  active  at  all  times.  The 
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requirement  for  the  radio  system  was  that  it 
operate  with  an  input  voltage  of  5  V  and  draw 
no  more  than  1  A  when  operating.  Due  to 
inefficiencies  and  the  slim  power  margins  to 
begin  with,  it  was  not  considered  effective  to 
use  a  DC-DC  converter  to  raise  the  input 
voltage  to  a  higher  level. 

The  next  constraint  was  that  the  radio  system 
would  need  to  support  command  services, 
downlink  services,  and  inter- satellite  services. 
The  intention  was  to  use  the  available 
allocations  in  die  UHF  and  VFH  bands, 
respectively,  for  the  first  two  services.  The 
inter- satellite  service  would  be  run  as  an 
amateur  radio  experiment  utilizing  packet 
radio  and  APRS  techniques.  The  minimum 
data  rate  for  the  command  and  inter-satellite 
services  would  be  1200  bits  per  second  while 
the  minimum  data  rate  for  the  telemetry  data 
would  be  9600  bits  per  second. 

The  solution  for  the  flight  radio  system  would 
need  to  meet  the  3CS  size  and  weight 
constraints.  While  this  never  became  a  major 
issue,  the  overall  design  team  tried  to 
minimize  weight  whenever  possible  because 
the  satellite  stack  was  always  close  to  its 
maximum  allowed  weight  based  on  launch 
constraints. 

Any  system  that  was  chosen  would  need  to 
pass  qualification  testing.  The  radio  system 
would  be  designed  to  survive  the  Hitchhiker 
vibration  qualification  testing.4  The  radio 
would  also  need  to  survive  thermal  cycles 
from -20°  C  to  +  60°  C. 

One  design  constraint  that  was  explicitly  not 
imposed  was  for  the  components  to  be 
radiation  hardened.  This  decision  was  made, 
primarily,  because  the  expected  lifetime  of  the 
satellites  on  orbit  would  be  only  a  few  months. 
Given  this  short  expected  mission  lifetime,  it 
was  decided  not  to  expend  the  extra  cost  for 
explicit  radiation  hardening.  The  project  team 


decided  that  between  having  the  radios 
mounted  in  aluminum  boxes,  the  use  of  a 
redundant  configuration,  and  the  ability  to 
reset  the  radios  via  the  flight  computer,  the 
risk  of  total  failure  due  to  radiation  effects 
would  be  small  enough  to  warrant  using 
commercial- grade  parts. 

Goals 

The  first  design  goal  was  to  provide  for  all  of 
the  radio  services  in  a  single  unit  rather  than 
having  frequency- specific  radios.  This  would 
help  minimize  weight  and  total  power 
consumption.  If  a  single  radio  could  be  used, 
a  secondary  design  goal  would  be  for  the 
flight  radio  subsystem  to  provide  a  software 
control  of  frequency  settings  and  radio 
parameters  that  would  be  under  the  control  of 
the  flight  computer  that  would  be  scheduling 
operations.  The  final  design  goal  was  to 
provide  for  a  redundant  design  to  allow  for  a 
graceful  failure  of  the  flight  radio  subsystem. 

Design  Solution 

The  design  of  the  flight  radio  was  based  on  an 
existing  commercially- available  product.  The 
following  paragraphs  describe  why  the 
components  were  chosen  and  how  the 
components  were  modified  for  flight. 

Radio  Choice 

Based  on  the  design  constraints,  the  Kenwood 
TH-D7  transceiver  was  chosen  as  the  basis  for 
the  3CS  flight  radio.  The  following  features 
were  key  to  selecting  this  particular  model: 

a.  The  radio  would  operate  with  a  5  V 
supply  voltage  and  consume 
approximately  1  A  of  current  at  the 
highest  power  mode 

b.  The  radio  has  two  lower  power 
settings  thereby  allowing  for  power 
control  options 
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c.  The  radio  has  a  standard  RS-232 
interface  for  data  and  control 

d.  The  radio  has  an  integrated  modem 
thereby  eliminating  the  need  for  an 
external  modem.  The  radio  also 
provided  internal  support  for  packet 
communications  modes  that  can  be 
customized  by  commands  from  the 
flight  computer. 

e.  The  radio  could  be  easily  modified  for 
the  UHF  and  VHF  services  required. 
The  radio  had  built-in  support  for  the 
inter- satellite  link. 

An  additional  feature  that  was  found  to  be 
useful  was  that  the  TH-D7  stores  its  settings  to 
memory  so  that  they  are  not  lost  when  the 
radio  is  powered  off.  This  implies  that  the 
flight  software  does  not  need  to  re- load 
settings  each  time.  However,  this  would 
remain  an  option  to  help  recover  from  single¬ 
event  upsets. 

Because  the  basic  radio  components  were 
relatively  light  when  removed  from  the 
commercial  housing,  we  proceeded  to  design  a 
system  with  two  TH-D7  units  to  form  a 
redundant  flight  radio  subsystem.  The 
necessary  modifications  are  next  described. 

Necessary  Modifications 

Because  the  TH-D7  was  intended  for  a 
commercial  market,  it  has  a  number  of 
components  that  would  either  be  unnecessary 
in  a  flight  radio  (speaker  and  microphone)  or 
not  allowed  (zinc  alloy  plate  and  various 
plastics).  By  using  an  iterative  process,  a 
procedure  was  developed  to  exactly  modify 
the  radio  to  first  maintain  functionality  and 
second  to  eliminate  all  components  that  were 
not  necessary  for  flight  or  had  to  be  modified 
to  pass  materials  compatibility.  The  main 
materials  problem  was  with  the  zinc  alloy 
chassis  plate  used  in  the  radio.  This  was 
replaced  by  an  equivalent  aluminum  plate  of 
the  same  form  factor.  The  procedure  was 


codified  into  a  step-by-step  procedure  to  be 
used  in  preparing  the  actual  flight  radios.5 
Figure  2  illustrates  an  exploded  view  of  the 
initial  radio  components  and  the  ones  finally 
kept  in  the  flight  units.  The  circuit  boards 
were  conformal  coated  and  held  together  with 
staking  compound  and  lacing  cord  as  shown  in 
Figure  3.  The  main  functional  modification  to 
the  radio  was  to  wire  it  to  always  to  be  “on”  so 
that  it  would  be  operational  whenever  power 
was  applied. 

During  testing  of  the  radio’s  performance,  we 
discovered  that  the  manufacturer- supplied 
dual-band  antenna  did  not  perform  well  at 
VHF  frequencies.  The  performance  was  10 
dB  below  that  of  a  tuned  blade  antenna  for  the 
VHF  frequency.  We  replaced  the  stock  dual¬ 
band  antenna  with  a  different  commercial 
dual-band  antenna  that  was  only  5  dB  below 
the  tuned  blade  performance  at  VHF  and 
within  1  dB  of  tuned  blade  performance  at 
UHF. 

Redundant  Design 

One  of  the  design  goals  was  to  produce  a 
redundant  flight  radio  sub -system  for  the  3CS 
satellites.  The  design  was  realized  by  using 
two  TH-D7’s  in  a  primary  and  backup 
configuration.  Each  radio  would  individually 
receive  power  only  when  the  power  sub¬ 
system  was  commanded  to  do  so  by  the  flight 
computer.  Each  radio  was  individually 
addressable  by  the  flight  computer  through  its 
RS-232  data  port.  Each  radio  uses  its  own 
dual-band  antenna  (no  antenna  cross 
switching).  A  Basic  Stamp  microcontroller 
was  added  to  the  design  to  ensure  proper  radio 
power  up.  Through  testing,  we  found  that  on 
occasion,  the  TH-D7  would  not  properly 
initialize  when  power  was  first  applied.  The 
microcontroller  monitors  the  input  line  to 
determine  when  the  radios  are  powered.  If  the 
microcontroller  detects  that  power  has  been 
applied  to  the  radio  but  the  radio  does  not 
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Figure  2  -  Original  TH-D7  components  and  the  parts  kept  for  the  flight  radio  system 


activate,  then  the  microcontroller  strobes  the 
corresponding  TH-D7  to  emulate  a  user 
cycling  the  on/ofif  switch.  We  have  found  that 
the  radio  will  properly  activate  after  this 
procedure.  A  separate  circuit  board  was 
designed  and  fabricated  for  the 
microcontroller  and  added  to  the  overall  flight 
radio  design. 

Each  subsystem  in  the  3CS  design  is  housed  in 
its  own  aluminum  box  to  provide  low-level 
radiation  shielding  and  to  provide  some  radio 
frequency  isolation  and  minimize  interference 
between  subsystems.  The  flight  radio  is  no 
exception.  The  housing  for  the  flight  radio 
was  designed  to  hold  both  TH-D7  radio  circuit 


boards  and  the  microcontroller  circuit  board. 
After  assembly,  the  radio  units  were  delivered 
to  ASU  for  integration  with  the  other  satellite 
components. 

The  wiring  diagram  for  the  redundant 
configuration  is  illustrated  in  Figure  4  and  one 
of  the  flight  units  being  assembled  with  its 
aluminum  housing  is  illustrated  in  Figure  5.  A 
manual  for  the  integrated  design  was  produced 
to  guide  software  developers  and  for 
operations  training.6 
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Figure  3  -  Modified  TH-D7  circuit  boards  that  are  conformal  coated  and  use  staking  compound 
to  separate  the  boards. 


Cable  and  Wiring 


Figure  4  -  Wiring  diagram  for  the  flight  radio  subsystem. 
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Figure  5  -  Flight  radio  unit  undergoing  final  assembly  into  aluminum  housing. 


Design  Validation  and  Testing 

To  validate  the  design,  an  extensive  test 
program  was  developed  to  ensure  that  no 
functionality  was  lost  as  the  radios  were 
modified,  assembled  into  the  flight  units,  and 
then  delivered  for  integration  into  the  satellite. 
The  first  step  in  the  process  was  to  start  with 
the  Manufacturer’s  Acceptance  Test  Plan 
where  the  required  functions  were  tested, 
operational  voltage  and  power  confirmed,  and 
radio  transmission  format  and  power  were 


validated.7  This  test  was  derived  from 
extensive  experimenting  with  the  radio’s 
performance  and  developing  automated  scripts 
that  would  exercise  the  radio’s  set  up  and 
configuration.  This  test  became  the  baseline 
for  subsequent  functional  and  characterization 
testing.  The  test  sequence  was  also  used  to 
illustrate  how  the  radios  could  be  programmed 
for  the  software  development  team.  After  the 
electronics  on  each  TH-D7  were  modified, 
and  before  assembling  into  the  flight  unit,  the 
individual  unit  was  tested  for  proper 
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functionality.  This  test  was  then  performed 
again  after  flight  unit  assembly.  This  test 
procedure  could  then  be  re-run  after  other 
testing  to  validate  proper  functionality. 

To  validate  that  the  flight  radio  would  pass 
acceptance  testing,  an  engineering  unit  was 
produced  and  subjected  to  thermal  cycle 
testing  and  vibration  testing.  The  vibration 
testing  was  at  full  shuttle  qualification  levels. 
A  visual  inspection  and  a  test  for  proper 
functionality  were  performed  after  the 
vibration  testing  to  ensure  that  the  units 
survived. 

Finally,  a  link  analysis  was  performed  to 
ensure  that  link  closure  would  be  possible 
with  the  radio  system.8  While  link  closure  is 
possible,  it  may  not  be  possible  to  downlink 
an  entire  uncompressed  image  during  a  single 
pass  to  a  single  ground  station.  It  may  be 
required  to  have  several  ground  stations 
receive  the  image  segments  and  then  re¬ 
integrate  the  image  in  software. 

Lessons  Learned 

One  goal  of  the  3CS  program  is  to  educate  and 
have  cooperation  between  the  students  at  all 
three  universities.  We  believe  that  such  a  goal 
was  very  much  a  major  part  of  the  program  so 
far.  In  this  section  we  will  examine  some  of 
the  lessons  learned  from  the  process  of 
developing  the  communications  sub-system 
for  the  3CS  program. 

Distributed  Project  Environment 

By  the  very  nature  of  a  university,  the  students 
will  come  and  go  on  a  project.  Sometimes 
this  happens  every  few  months.  With  the  3CS 
program,  this  was  happening  across  three 
universities  that  are  geographically  separated 
as  well.  By  using  teleconferences  and  the 
Web,  information  can  be  shared  on  frequent 
basis  and  updated  rapidly  so  that  the  distance 


between  universities  is  not  a  big  problem. 
One  lesson  from  this  distributed  environment 
is  that  documentation  such  as  users’  manuals 
need  to  be  developed  as  early  in  the  process  as 
possible.  These  help  the  team  members  at 
other  locations  to  learn  the  design  and  see  how 
the  design  will  begin  to  integrate  with  other 
subsystems.  This  can  also  assist  in  software 
development.  As  the  design  process  iterated 
and  changes  were  made,  the  manuals  could  be 
updated  and  distributed  over  the  Web  in  near 
real-time  to  keep  all  team  members  current. 

Testing  and  Documentation 

While  testing  is  required  to  show  that  a  part  is 
functioning  properly  or  to  validate 
performance,  it  is  also  useful  as  a  training 
method.  As  students  cycled  through  the 
program,  we  used  detailed  testing  procedures 
to  teach  them  how  the  radio  units  worked  and 
what  type  of  performance  to  expect.  A 
corollary  to  this  is  that  spare  test  units  need  to 
be  procured  because  the  test  units  are  often 
broken  as  new  personnel  learn  the  test 
procedures. 

From  our  experience,  most  students  are  not 
taught  formal  testing  procedures  in  their 
laboratory  classes.  Therefore,  the  formal 
testing  of  the  radios  introduces  the  students  to 
formalized  and  methodical  procedures.  Prior 
to  problems  occurring,  we  have  generally 
found  the  students’  attitudes  to  be  that  formal 
procedures  are  not  really  necessary.  After  the 
problem  occurs,  they  see  that  the  formal 
procedure  can  assist  the  engineer  in  finding 
the  fault  and  verifying  that  the  problem 
resolution  has  worked. 

We  also  used  the  detailed  testing  to  capture 
design  mistakes.  In  one  case,  it  forced  us  to 
re-design  the  antenna  interface  and  change 
some  of  the  operational  philosophy  for  the 
satellite.  This  was  caught  before  the  flight 
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radio  units  were  delivered  and  integrated  with 
the  rest  of  the  satellite. 

Manufacturer  Support 

The  manufacturer’s  distributor  may  be  the 
least  knowledgeable  about  the  details  of  the 
components  in  the  device.  This  is  important 
both  for  materials  and  for  operating 
characteristics.  We  encountered  difficulties  in 
determining  the  materials  properties  of  certain 
components  on  the  TH-D7.  We  eventually 
were  able  to  track  down  the  original 
manufacturer  to  obtain  some  of  the 
information.  It  was  necessary  to  conformal 
coat  the  component  to  ensure  that  it  would 
pass  NASA  safety  criteria.  A  similar  problem 
was  encountered  with  the  intermediate 
frequency  filter  bandwidth  specification  for 
the  radios  that  are  required  to  complete  the 
DD  1494  forms.  In  this  case,  the  part  needed 
to  be  located  in  the  original  manufacturer’s 
catalog  to  obtain  the  specifications.  The 
lesson  learned  for  both  cases  is  that  the  user 
will  often  need  to  reverse  engineer  a  part  to 
complete  the  paperwork  necessary  for  flight. 
Adequate  time  needs  to  be  placed  in  the 
schedule  for  these  types  of  unanticipated 
activities. 

Conclusions 

A  commercial- grade  device  can  be  readied  for 
space  flight  and  tested  to  pass  basic  safety  and 
materials  concerns.  The  usual  engineering 
lessons  of  adequate  documentation,  well- 
specified  procedures,  and  traceable 
performance  become  especially  important 
when  teaching  students  and  when  performing 
a  distributed  design.  As  might  be  expected, 
more  time  is  actually  spent  on  this  type  of 
paperwork  activity  than  on  actual  design 
work.  However,  good  documentation  and 
good  practices  make  the  ability  to  work 
together  across  school  boundaries  an 
achievable  goal. 
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ABSTRACT  -  The  Three  Corner  Satellite  constellation  is  a  cluster  of  three 
nanosats  to  be  flown  as  part  of  the  US  Air  Force  University  Nanosat  program. 
This  paper  describes  the  mission  objectives,  the  mission  design  approach,  the 
satellite  components,  and  the  means  for  command  and  control  of  the  mission 
elements.  The  satellites  were  completed  and  delivered  in  2002  and  are  awaiting 
launch  from  the  NASA  space  shuttle. 


1  -  INTRODUCTION 

The  Three  Comer  Satellite  (3CS)  constellation  is  a  cluster  of  three  nanosatellites  that  are  part  of  the 
US  Air  Force  University  Nanosat  program.  The  3CS  project  was  begun  in  January  1999  and  the 
cluster  of  satellites  is  presently  awaiting  launch  in  2003  from  the  Space  Shuttle.  The  satellites  are 
shown  in  their  launch  configuration  in  Fig.  1.  The  3CS  project  is  a  joint  effort  of  the  faculty,  staff, 
and  students  at  the  participating  universities:  Arizona  State  University  (ASU),  the  University  of 
Colorado  at  Boulder  (CU),  and  New  Mexico  State  University  (NMSU).  Consult  the  [Unde  99], 
[Hans  99]  and  [Hora  99]  for  further  details  on  the  baseline  design  and  mission  concepts. 

The  3CS  mission  has  four  primary  and  three  secondary  objectives.  The  primary  mission  objectives 
include:  stereo  imaging,  virtual  formation  flying,  inter-satellite  communications,  and  end  to  end 
command  and  data  handling.  The  science  will  include  imaging  of  clouds  and  other  atmospheric 
structures  using  a  satellite  formation.  After  deployment,  the  three  satellites  will  operate  together 
using  formation  flying  techniques.  This  will  be  accomplished  while  using  virtual  formation 
communications,  a  technology  that  allows  the  satellites  to  operate  as  a  network  utilizing 
communication  and  data  links.  Finally,  the  formation  will  use  distributed  and  automated  operations. 
This  allows  both  individual  nanosats  and  the  entire  formation  to  be  reconfigured  for  optimum  data 
gathering,  command  and  control,  and  communication. 

The  secondary  mission  objectives  include:  validation  of  a  MEMS  heater  chip  for  a  Free  Molecule 
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Fig.  1  -  Three  Comer  Satellite  launch  configuration. 
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Micro  Resistojet  (FMMR)  propulsion  system,  demonstration  of  generic  nanosatellite  bus  design, 
and  student  education. 

One  of  the  principal  features  of  the  3CS  mission  is  that  all  three  nanosats  are  based  on  a  similar 
design.  Each  university  has  responsibility  for  different  subsystems,  and  all  components  are  designed 
to  be  common  to  each  of  the  satellites.  Each  school's  team  is  comprised  of  a  faculty  member  and 
graduate  and  undergraduate  students.  Each  school  leads  in  its  respective  areas  of  expertise  and  on 
strengths  proven  on  past  projects  as  follows: 

a.  ASU  -  program  management,  systems,  structures,  electrical  power,  micropropulsion, 
integration  and  testing,  safety,  configuration  management  and  quality  assurance, 

b.  CU  -  science  (imaging),  command  and  data  handling,  mission  operations,  and 

c.  NMSU  -  communications 

Using  this  team  concept,  the  design  was  developed  at  the  lead  school  with  review  and  comment  by 
the  partner  schools.  In  addition  to  the  design  work,  the  team  members  needed  to  verify  that  all 
components,  materials,  and  design  features  would  pass  the  NASA  flight  safety  reviews  for  launch 
from  the  Space  Shuttle.  This  paper  concentrates  on  the  design  of  the  satellites.  Since  the  individual 
subsystems  were  produced  by  different  partner  members  at  each  school,  the  overall  set  of 
components  needed  to  be  matched  and  integrated  at  final  assembly. 


2  -  SATELLITE  SUBSYSTEMS 

The  3CS  satellites  were  designed  and  fabricated  as  three  common  satellites.  The  main  differences 
are  antenna  placement,  the  inclusion  of  the  FMMR  test  electronics  on  two  cluster  members,  and 
some  additional  solar  cells  on  one  satellite.  In  this  section,  we  will  describe  the  common 
components  for  each  satellite  necessary  for  the  formation  flying  mission  goals.  This  includes  the 
structure,  the  power  system,  the  end-to-end  data  system,  the  imaging  system,  and  the 
communications  system. 


2.1  -  Structure 

The  structure  for  each  satellite  is  based  on  a  machined  6061 -T6  aluminum  isogrid  structure  as 
illustrated  in  Fig.  2.  The  structure  is  hexagonal  in  cross  section  with  the  major  axis  for  the  satellite 


Fig.  2  -  Isogrid  structural  components. 


being  44.7  cm  and  the  minor  axis  for  the  satellite  is  39.4  cm.  The  height  of  each  satellite  is  29.2 
cm.  As  can  be  seen  in  Fig.  2,  the  side  panels  and  the  top  and  bottom  plates  form  an  interlocking 
structure.  Brackets  are  added  where  the  side  panels  abut  for  increased  rigidity.  The  aluminum  is 
anodized  except  for  electrical  contact  points.  The  side  and  top  panels  are  the  load-bearing  structure 
for  the  satellite.  The  structure  was  tested  to  verify  that  it  would  meet  required  strength  and 
vibration  mode  requirements  for  a  space  shuttle  payload. 


2.2  -  Power  Electronics 

The  Electrical  Power  System  (EPS)  is  composed  of  the  following  elements 

a.  solar  cells, 

b.  battery  pack, 

c.  inhibit  relays, 

d.  DC/DC  converter,  and 

e.  microprocessor  controller. 

The  system  elements  are  organized  as  illustrated  in  Fig.  3.  The  power  from  the  battery  and  the  solar 
cells  is  distributed  as  +5  V  regulated  and  +12  V  unregulated  power.  The  12-V  power  is  used  by  the 
cameras  and  imaging  electronics.  The  5-V  power  is  for  other  components.  All  systems  but  EPS 
have  in-line  switches  controlled  by  EPS  to  prevent  power-on  prior  to  safe  operating  conditions 
being  established  after  launch  and  to  control  the  satellite  power  budget.  The  EPS  microcontroller  is 
a  PIC  microcontroller  with  a  watchdog  timer.  The  EPS  microcontroller  is  responsible  for 

a.  sampling  and  storing  health  and  welfare  telemetry  measurements, 

b.  listening  for  end-to-end  data  system  commands  to  enable/disable  individual 
components,  and 

c.  acting  as  a  watchdog  timer  for  the  end-to-end  data  system. 

The  inhibit  relays  are  required  to  prevent  premature  energizing  of  the  electronics  during  launch. 
There  are  three  latching  relays  between  each  power  source  and  the  load.  There  is  also  one  latching 
relay  in  the  ground  leg  for  each  power  source.  These  relays  are  set  by  the  inhibit  timer  electronics 
in  the  MSDS  portion  of  the  launch  configuration. 
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Fig.  3  -  Electrical  power  system  components. 


The  solar  panels  use  dual-junction  gallium  arsenide  solar  cells  that  are  commercially  manufactured. 
The  side  panels  and  top  panel  of  each  satellite  holds  the  solar  panel  structure  in  place.  Each  panel 
consists  of  two  strings  of  nine  cells  with  each  cell  generating  approximately  2.4  V .  The  solar  panel 
contains  a  current  meter  and  diode  protection.  The  solar  panel  configuration  is  shown  in  the  left 
half  of  Fig.  4 
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Fig  4.  -  Electrical  Power  System  components:  solar  cell  panel  and  battery. 

The  battery  portion  of  the  EPS  is  composed  of  a  pack  often  NiCd  cells  with  2300  mAh  of  capacity. 
The  battery  is  illustrated  in  the  right  half  of  Fig.  4  which  shows  the  packaging  into  a  vented  box 
with  absorbent  material  to  mitigate  any  leakage  effects. 


2.3  -  End-to-End  Data  Systems 

The  End-to-End  Data  System  (EEDS)  is  an  integration  of  computer  hardware,  software,  procedures, 
and  personnel  for  cluster  command  and  control  and  data  handling.  The  hardware  component  in 
each  satellite  includes  an  823  Power  PC  flight  computer  having  16  MB  of  RAM,  8  MB  of  RAM 
organized  as  a  solid  state  recorder,  and  a  critical  decoder  for  processing  initialization  commands. 

The  software  is  stored  on  disk  and  in  ROM.  The  flight  software  is  disabled  until  after  deployment 


from  the  MSDS.  The  software  uses  a  commercial  operating  system  (VxWorks)  and  extensive  use 
of  commercial  software  tools  for  controlling  the  satellites.  The  primary  tool  is  the  System  Control 
Language  (SCL)  to  program  rules  to  monitor  the  health  and  welfare  of  the  satellite.  The  current 
state  of  the  satellite  can  initiate  scripts  to  take  counter  measures  for  detected  faults.  The  rules  can 
also  be  used  to  generate  scripts  to  perform  specific  functions,  e.g.  initialize  the  radio  system  or  the 
imaging  system.  Operational  science  events  such  as  taking  a  sequence  of  pictures  are  also  SCL- 
based  activities. 

The  command  structure  for  the  satellites  is  based  on  specific  files  sent  from  the  ground  stations, 
inter- sate llite  messages,  and  pre-stored,  timed  commands.  The  scheduling  software  can  build  a 
sequence  of  operational  commands  to  be  executed  between  ground  station  contact  times. 


2.4  -  Imaging 

The  imaging  system  for  the  satellites  is  based  on  four  cameras  per  satellite  with  the  goal  of 
producing  images  of  clouds  from  orbit.  There  are  two  cameras  on  the  top  bulkhead  and  two 
cameras  on  the  bottom  bulkhead.  The  cameras  interface  with  EEDS  for  data  and  EPS  for  power. 
The  cameras  are  commercial  cameras  using  a  640  x  480  pixel  CMOS  sensor.  The  cameras  have  full 
automatic  exposure  control.  The  on-board  algorithms  will  be  used  to  evaluate  image  quality  and 
prioritize  the  images  for  downloading.  The  imaging  cameras  are  illustrated  in  the  right  portion  of 
Fig.  5  and  the  mounting  in  the  bulkhead  in  shown  in  the  left  portion  of  Fig.  5. 
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Fig.  5  -  Imaging  system:  placement  on  the  satellite  and  the  digital  camera  in  the  imaging 
system. 


2.5  -  Communications 

The  communications  system  is  based  on  commercial  amateur  radio  hardware  that  has  been 
modified  for  an  extended  frequency  range  outside  the  amateur  bands.  The  radios  are  arranged  as  a 
dual  redundant  flight  radio  in  each  satellite.  Each  radio  is  software  programmable  via  the  EEDS  to 
set  frequency,  power,  and  operating  characteristics.  The  radios  are  only  powered  on  when  supplied 
power  by  the  EPS  to  help  control  the  overall  satellite  power  budget  with  each  radio  being 
individually  powered.  The  nominal  operating  mode  will  be  to  have  one  radio  on  at  all  times  in 
receive  mode  to  listen  for  commands.  The  radios  use  a  VHF  frequency  for  the  data  downlink,  UHF 
frequency  for  the  command  uplink,  and  a  different  UHF  frequency  for  the  inter-satellite  crosslink 
communications.  All  communications  use  a  frequency  shift  keying  technique  and  the  AX. 25  packet 
communications  protocol  at  the  physical  channel  level.  The  data  rates  available  on  the  radios  are 
1200  bps  and  9600  bps.  The  maximum  transmission  power  is  1  W. 

The  antenna  system  uses  a  commercial  dual-band  antenna  for  each  radio.  The  antennas  on  the  two 


satellites  that  are  joined  in  the  2x1  launch  configuration  have  their  antennas  inserted  into  a  sheath 
inside  the  other  satellite  for  launch.  Upon  satellite  separation,  the  antennas  are  withdrawn  from  the 
sheaths  without  use  of  a  deployment  mechanism. 

The  primary  ground  control  station  will  be  at  CU.  The  other  schools  (ASU  and  NMSU)  will  have 
compatible  ground  stations  to  be  used  as  backup  relay  points  for  both  commands  and  telemetry  by 
using  store  and  forward  data  files  in  either  direction.  The  uplink  data  files  can  be  commands, 
schedules,  or  revised  software.  The  relationship  between  the  satellites  and  the  ground  stations  is 
illustrated  in  Fig.  6. 
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Fig.  6  -  Line  diagram  of  communications  frequencies  and  ground  stations 


3  -  LAUNCH  CONFIGURATION 

The  satellite  cluster  launch  configuration  was  shown  in  Fig.  1.  The  2x1  satellite  configuration  was 
determined  by  vibration  limits  on  the  satellite  separation  systems.  This  configuration  consists  of 

a.  the  individual  satellites 

b.  the  Lightband  inter-satellite  separation  mechanism  between  the  two  joined  satellites 

c.  the  Starsys  separation  mechanism  between  the  launch  plate  and  the  satellite  on  it 

d.  the  Multiple  Satellite  Deployment  System  (MSDS)  that  holds  the  cluster 
configuration. 

For  the  purposes  of  this  project,  the  Lightband,  Starsys,  and  MSDS  components  are  “government 
furnished  equipment”  and  outside  the  control  of  the  3CS  project  team.  However,  the  satellites  need 
to  be  compatible  with  the  components.  Additionally,  the  timer  control  and  power  for  removing  the 
inhibits  are  controlled  through  the  MSDS  electronics.  The  electronic  signals  for  activating  the 
satellites  are  passed  through  the  Starsys  and  Lightband  components  to  the  cluster  members.  This 
integrated  system  is  delivered  to  NASA  to  be  mated  with  the  NASA  systems  for  launch. 


4  -  FORMATION  FLYING 

The  satellite  cluster  was  designed  to  meet  a  virtual  formation  mission.  That  is,  the  cluster 


performance  was  designed  to  be  based  on  relative  position  knowledge  and  not  on  relative  position 
control.  The  mission  science  goal  of  stereoscopic  imaging  is  based  on  using  software  and 
knowledge  of  the  satellite  position  from  the  orbital  elements  to  generate  the  composite  image  from 
the  individual  satellite  images.  Another  mission  goal  of  distributed  operations  is  facilitated  by  the 
use  of  inter-satellite  communication  links  to  provide  the  means  for  controlling  the  satellite  cluster 
by  being  able  to  relay  commands  from  a  ground  control  station  through  one  satellite  to  another 
satellite.  The  communications  internal  modem  also  has  a  short  messaging  service  that  can  be  used 
in  conjunction  with  the  normal  packet  communications  modes  to  relay  messages  between  the 
satellites  for  command  and  control  by  the  flight  computer  software. 
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ABSTRACT 

A  multi-platform  network  design  that  is  automated,  bi-directional,  capable  of  store  and  forward 
operations,  and  low-bandwidth  has  been  developed  to  connect  multiple  satellite  ground  stations 
together  in  real-time.  The  LabVIEW  programming  language  has  been  used  to  develop  both  the 
server  and  client  aspects  of  this  network.  Future  plans  for  this  project  include  implementing  a  fully 
operational  ground  network  using  the  described  concepts,  and  using  this  network  for  real-time 
satellite  operations.  This  paper  describes  the  design  requirements,  RF  and  ground-based  network 
configuration,  software  implementation,  and  operational  testing  of  the  ground  network. 
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INTRODUCTION 

Small  satellites  known  as  “Nano-sats”  are  more  commonly  being  designed  and  built  by  small 
organizations  and  research  institutions.  There  exists  a  need  for  a  scalable,  reconfigurable  ground 
station  network  for  use  by  these  smaller  organizations  that  may  not  have  the  time  or  money  to  design 
their  own  full-scale,  multi-site  satellite  ground  station  network.  For  such  a  network  to  be  easily 
useable  by  small  research  projects,  the  bulk  of  the  network  design  should  be  already  done.  The 
network  must  also  be  scalable  to  be  able  to  adapt  to  the  needs  of  the  particular  Nano-sat  project.  To 
demonstrate  this,  a  specific  Nano-sat  project  called  “3  Comer  Sat”  will  be  used  as  an  example. 

The  “3  Comer  Sat”  (3CS)  project  is  part  of  the  AFOSR/DARPA  University  Nanosatellite  program. 
It  is  a  joint  effort  between  Arizona  State  University,  University  of  Colorado  at  Boulder,  and  New 
Mexico  State  University.  The  project  is  building  a  constellation  of  3  satellites  that  will  perform  tests 
on  new  types  of  Nano-sat  technology  such  as  stereo  imaging  of  cloud  and  land  formations,  formation 
flying,  and  new  types  of  command  and  control  scheduling.  Because  of  the  nature  of  the 
constellation  and  communication  system  configurations,  a  custom  design  for  the  ground  station 
communications  network  is  needed. 


This  paper  will  discuss  a  means  of  constructing  such  a  ground  network  using  the  LabVIEW™ 
version  6  software  suite  developed  by  National  Instruments™.  The  network  is  comprised  of  two 
different  Multi-platform  Virtual  Instruments  (Vis).  These  Vis  were  designed  to  be  compatible  with 
many  computing  platforms  and  operating  systems.  In  this  paper,  we  will  examine  the  design  goals 
for  this  ground  network,  the  server/client  configuration,  the  data  interaction  between  the  server  and 
client,  selection  of  a  programming  environment  for  implementation,  and  the  virtual  instruments  that 
were  created  to  complete  the  design. 


GROUND  NETWORK  DESIGN  GOALS 

The  ground  network  has  several  key  design  requirements  that  are  defined  by  the  nature  of  the 
satellite  configuration.  These  requirements  were  not  able  to  be  met  with  the  use  of  conventional, 
commercially  available  satellite  networking  systems.  Thus,  a  new  ground  network  system  will  be 
designed  and  tested  with  the  following  requirements  in  mind: 

1)  The  ground  communications  network  shall  support  a  minimum  of  three  remote  ground 
stations  from  a  control  station. 

2)  The  ground  communications  network  will  provide  a  means  to  remotely  initialize  each  remote 
ground  station. 

3)  The  ground  communications  network  will  provide  a  means  to  monitor  the  status  of  the 
remote  ground  stations. 

4)  The  ground  communications  network  will  provide  data  transfer  between  each  remote 
terminal  and  the  central  control  station. 

5)  The  data  transfer  function  will  include  the  ability  for  store-and-forward  of  bi-directional  data. 

6)  The  store-and-forward  data  transmission  will  have  the  means  to  send  data  from  the  control 
station  to  each  remote  terminal  for  later  transmission  to  the  satellites. 

7)  The  store-and-forward  data  transmission  will  have  the  means  to  record  satellite  data  at  each 
remote  terminal  for  later  transmission  to  the  control  station  in  the  event  that  the  internet  link 
goes  down. 

8)  The  control  station  and  the  remote  terminals  shall  have  synchronized  clocks 

9)  The  ground  communications  network  shall  have  security  measures  that  protect  against 
unauthorized  use  of  the  system 

10)  The  ground  communications  network  software  will  be  capable  of  execution  on  current 
Windows  (98/NT/2000/XP),  Unix,  Macintosh,  and  Linux  operating  systems. 

It  is  the  goal  of  the  3CS  communications  team  to  meet  all  design  requirement  expectations  by  using 
new,  innovative  implementation  methods.  These  methods  will  allow  such  a  ground  network  system 
to  be  customizable  for  future  Nano-sat  or  similar  projects. 


GENERAL  IMPLEMENTATION 


The  ground  network  will  consist  of  one  “Server”  and  multiple  “Client”  systems.  The  server  and 
client  labels  that  are  given  to  these  stations  describe  the  nature  of  operation  and  data  flow  present  at 
that  location.  The  server  will  consist  of  one  computer  at  the  Nano-sat  mission  control  center.  This 
station  is  responsible  for  all  data  that  is  distributed  to  the  constellation,  and  collected  from  the 
constellation.  It  is  also  responsible  for  the  operation  of  the  individual  ground  communication 
stations.  The  client  will  consist  of  a  computer  running  at  each  of  the  ground  stations.  This  client  will 
act  as  a  conduit  for  all  information  that  is  to  pass  to  or  from  the  satellite  constellation.  It  is  also 
responsible  for  control  of  antenna  movement  to  be  able  to  track  satellites  across  the  sky  during  a 
pass. 

It  is  desirable  to  have  all  client  stations  collaborating  to  be  able  to  schedule  operations  based  on 
satellite  passes.  For  example,  one  of  the  ground  stations  may  have  a  better  vantage  point  for 
communications  to  the  satellite  constellation  than  the  other  ground  stations.  For  this  reason,  all 
satellite  communications  are  done  through  that  ground  station  for  that  particular  pass,  until  another 
station  becomes  a  better  candidate.  The  station  with  the  best  accessibility  to  the  satellite 
constellation  is  determined  by  the  personnel  at  the  mission  control  center,  who  will  have  satellite 
pass  prediction  software  aiding  them  in  their  decision.  The  communication  connection  between  the 
clients  and  server  are  made  by  using  standard  TCP/IP  sockets  over  the  internet.  This  allows  the 
client  stations  to  be  anywhere  in  the  world,  theoretically. 


SERVER  IMPLEMENTATION 

The  program  that  runs  on  the  server  computer  was  developed  using  the  LabVIEW™  version  6 
software  suite  developed  by  National  Instruments™.  This  development  environment  allows 
graphical  construction  and  modifications  of  executable  programs  called  “Virtual  Instruments”  (VI). 
See  figure  2  for  an  example.  A  VI  was  created  that  performs  several  tasks: 

1)  Disperses  data  that  is  to  be  transmitted  to  the  satellite  cluster  to  a  specific  ground  station  or 
multiple  ground  stations. 

2)  Receives  live  or  stored  data  from  ground  stations  that  has  been  received  from  the  satellite 
constellation. 

3)  Provides  a  Graphical  User  Interface  (GUI)  to  personnel  at  mission  control,  allowing  them  to 
control  ground  station  network  operations  at  each  individual  ground  station,  and  the  network 
as  a  whole.  Figure  3  displays  the  front  panel  of  this  GUI. 

4)  Provides  an  internet-based  interface  to  other  mission  control  computers  for  real-time  data 
acquisition  and  analysis. 


Figure  2:  An  example  of  an  actual  Vi’s  source  code 
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The  server  is  programmed  to  communicate  with  the  clients  using  a  LabVIEW  communications 
driver  that  is  running  on  the  client  computers  in  parallel  with  the  client  Vis.  This  driver  is  called  the 
“VI  Server”.  It  allows  other  Vis  that  are  running  at  another  location  to  control  the  local  VI,  and  also 
to  receive  data  from  the  local  VI.  The  VI  Server  drivers  use  a  standard  TCP/IP  internet  connection  as 
the  communication  backbone. 

The  data  received  from  the  clients  by  the  server  is  split  into  two  categories:  Satellite  data  and  VI 
display  data.  The  VI  display  data  is  extracted  and  used  to  generate  displays  on  the  server  computer 
that  are  identical  to  each  of  the  displays  on  the  client  computers.  These  displays  are  updated  approx 
every  2-3  seconds.  The  satellite  data  then  remains,  and  is  made  available  for  other  computers  in  the 
mission  control  center  to  acquire  via  a  standard  TCP/IP  telnet  connection.  For  simplicity,  the  data 
that  comes  from  the  individual  ground  stations  is  tagged  as  being  from  a  particular  station,  but  is  not 
recombined  by  the  server  computer.  The  tagged  data  is  combined  by  another  mission  control 
computer  based  on  the  needs  of  the  mission  control  team. 

The  data  transferred  from  the  server  to  each  of  the  clients  is  categorized  in  a  similar  fashion.  There 
again  exists  two  types  of  data:  Ground  station  control  data,  and  satellite  data  (commands,  etc.)  to  be 


transmitted.  The  ground  station  control  data  is  generated  by  the  GUI  on  the  server  display.  For 
example,  if  a  mission  control  team  member  clicks  on  a  graphical  toggle  switch  on  the  server  display 
that  is  associated  with  the  client  at  NMSU,  the  matching  button  gets  toggled  on  the  client  computer 
itself.  The  satellite  transmit  data  is  generated  not  by,  the  server,  but  by  other  mission  control 
computers.  This  data  is  merely  relayed  by  the  server  to  the  appropriate  client(s)  as  defined  by 
mission  control  personnel. 


CLIENT  IMPLEMENTATION 

The  client  computer  is  running  at  the  site  where  the  actual  ground  satellite  communications  hardware 
is  located.  The  computer  is  connected  to  ground  station  hardware  that  transmits  and  receives  data 
to/from  the  satellite  constellation.  The  computer  is  also  connected  to  a  standard  full-time  internet 
access  point.  The  program  that  runs  on  the  client  computers  is  also  a  VI.  This  VI  performs  the 
following  tasks: 

1)  Relays  data  from  the  server  at  mission  control  to  the  satellite  ground  communications  radio 
hardware. 

2)  Relays  data  from  the  satellite  ground  communications  radio  hardware  to  the  server  computer 
at  mission  control. 

3)  Transmits  health  and  status  of  client  VI  and  ground  station  equipment  to  mission  control. 

4)  Receives  commands  from  mission  control  to  change  client  VI  or  ground  station  equipment 
operation. 

5)  Stores  data  in  the  case  that  a  portion  of  communications  is  cut  off  between  client  and 
satellites  or  client  and  mission  control  server  computer.  The  data  is  forwarded  when 
communications  are  re-established. 

6)  Provides  a  graphical  user  interface  (GUI)  at  the  ground  station  location  for  on-site  control  of 
the  client  VI  in  case  of  emergency  operation.  See  Figure  4  for  a  view  of  this  GUI. 


Figure  4,  A  view  of  the  client  VI  GUI. 


The  “VI  Server”  driver  that  was  mentioned  above,  is  running  in  parallel  with  the  client  VI.  The 
driver  is  managing  communications  with  the  server  VI  via  standard  TCP/IP  methods.  The  driver 
then  separates  the  two  types  of  data  that  is  coming  from  the  server  computer.  The  ground  station 
control  command  data  is  extracted  and  used  to  modify  client  VI  operational  settings.  The  data  that  is 
intended  for  the  satellite  cluster  is  passed  along  to  the  client  VI  as  raw  data.  This  raw  data  is  then 
relayed  to  the  ground  station  communications  hardware. 

In  a  sense,  the  same  TCP/IP  socket  connection  is  being  used  for  both  raw  satellite  data,  and  ground 
station  command  and  control  data.  This  reduces  the  complexity  of  the  connection  that  is  required 
between  the  ground  stations  and  mission  control.  Any  reduction  in  complexity  from  the  mission 
control  standpoint  will  allow  mission  control  personnel  to  focus  on  flight  operations  instead  of  how 
the  data  will  be  transferred  to/from  the  satellite  constellation. 


CONCLUSION 


A  scalable,  reconfigurable,  and  automated  ground  network  system  is  a  desirable  feature  of  many 
satellite  projects.  In  the  case  of  university-based  Nano-sat  programs,  a  fairly  limited  budget  and 
limited  amount  of  manpower  puts  a  great  importance  on  efficiency  and  simplicity  of  the  systems  that 
are  used.  In  the  case  of  the  3  Comer  Sat  program,  the  capabilities  that  this  ground  network  system 
will  give  the  project  will  help  insure  the  success  of  the  mission.  In  this  example,  we  are  using  an 
off-the-shelf  product  to  create  an  acceptable  solution  to  the  logistical  problems  that  accompany  a 
satellite  project  that  uses  multiple  ground  communication  stations.  The  3CS  communications  team 
hopes  that  this  ground  network  design  might  be  helpful  to  other  Nano-sat  or  similar  programs  that 
are  in  need  of  such  system. 


